gdk: Allow internal management of source-side DnD
authorCarlos Garnacho <carlosg@gnome.org>
Fri, 8 Jan 2016 20:03:01 +0000 (21:03 +0100)
committerCarlos Garnacho <carlosg@gnome.org>
Tue, 19 Jan 2016 13:17:35 +0000 (14:17 +0100)
commitedc4374a634b1597e6c7a3e6136a54f4ed74bb4e
tree1f5a7bdc182ba2f98e1983f4afee83be294a0127
parenta50baba16058ea86c95269c2eff24a1c97ec34d2
gdk: Allow internal management of source-side DnD

We've traditionally left GTK+ to handle the input side of things,
letting GDK only manage the windowing-specific messaging. This
way of splitting responsibilities is not compatible however with
some backends, we must fold then input management at the DnD stage
into GDK (and backends) domain.

The gdk_drag_context_manage_dnd() call is meant to be the entry
point for this mode of operation, if the drag and drop operation
becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform
grabs, nor manage input events itself.

As a consequence of this, different aspects now belong to the
backend GdkDragContext implementation:
- Because the caller doesn't see keyboard events anymore,
  keyboard navigation must be managed in GDK, so is the decision
  of the current action based on modifiers/button pressed.
- Because the caller won't see input events in general, the lifetime
  of the drag and drop operation is now communicated through the
  ::drop-performed, ::dnd-finished and ::cancel events
- Because the caller doesn't participate anymore on the action
  being chosen, the pointer cursor must be set by the backend.
  The caller is rather notified of the final action through the
  ::action signal.

The caller is still responsible of dealing with the corresponding
GdkSelection, ensuring its ownership and communicating the supported
mimetypes.
gdk/gdkdnd.c
gdk/gdkdnd.h
gdk/gdkdndprivate.h